Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove highlighting from secondary messages #51485

Merged
merged 1 commit into from
Jul 22, 2018

Conversation

estebank
Copy link
Contributor

@estebank estebank commented Jun 11, 2018

Deemphasize the secondary messages so that all other highlights stand
out more.

@rust-highfive
Copy link
Collaborator

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 11, 2018
@estebank
Copy link
Contributor Author

I'm sure this might be controversial. There was a ticket asking for this that I couldn't find now.

I'm looking for feedback.

cc @nikomatsakis @GuillaumeGomez @jonathandturner @petrochenkov

@GuillaumeGomez
Copy link
Member

Can you post the original look too please? So we can see the differences more easily.

@estebank
Copy link
Contributor Author

estebank commented Jun 11, 2018

Before:

After:
screen shot 2018-06-10 at 19 44 27

The original ask was when dealing with lifetime errors involving 'static:

Before:

After:

The highlighting makes the first note seem more important than it is (alternatively we could highlight notes merged to a span instead, but I want to reduce highlighting).

@estebank

This comment has been minimized.

Deemphasize the secondary messages so that all other highlights stand
out more.
@GuillaumeGomez
Copy link
Member

I don't have strong opinion in here. It allows to focus more easily on the other messages, which depending on what we want might be better or worse. So do we want to focus on help messages, attract users' attention to tips or do we want to keep the attention on the first/initial/main error?

@estebank
Copy link
Contributor Author

estebank commented Jun 12, 2018

My reasoning is that we're already using span_notes and notes as part of the same "narrative", while on the cli output we give span_notes a highlight but not to notes, incorrectly differentiating them. I think it is a bikeshed-ing argument in any direction, but I'd like us to be consistent.

So do we want to focus on help messages, attract users' attention to tips or do we want to keep the attention on the first/initial/main error?

For what is worth, many vocal users want less highlighting and to focus on the main message. The proposed output would train people that bold white is where to look for the main message.

@cramertj
Copy link
Member

I have no strong opinions one way or another.
@bors r? @GuillaumeGomez

@GuillaumeGomez
Copy link
Member

I'd just like to have at least @nikomatsakis or @jonathandturner's opinion before r+ing it.

@mark-i-m
Copy link
Member

Personally, I think this is an improvement.

@sophiajt
Copy link
Contributor

While I think the general rule of thumb to decrease the amount of bold is probably a good thing, to my eyes, this is a small step backward. Specifically, this problem spot seems to have gotten worse:

screenshot from 2018-06-20 06-00-53
screenshot from 2018-06-20 06-02-51

In the first version, it's easy for the eye to separate out the first message from the second. In the revision, these visually merge together, which takes a little longer to parse at first glance.

One way to work around this might be to remove the bold, but add in a blank line. I think @nikomatsakis and I settled on using bold so that we wouldn't use too much spacing out of lines, but perhaps it's worth exploring again?

@estebank
Copy link
Contributor Author

The thing is that those three lines are actually part of the same narrative, so it doesn't seem right to differentiate them as highly as we currently are.

@pietroalbini
Copy link
Member

Ping from triage! @nikomatsakis can you check in on this?

@estebank
Copy link
Contributor Author

@nikomatsakis could you take a look at this? The diff is minimal, and the output change can be seen in the screenshots above.

The only remaining argument remaining is @jonathandturner's worry that multiple notes one after the other will be harder to read. I don't think that is the case, and that the current unnecessary differentiation between notes with spans and without them is more detrimental to readability than this PRs output.

@nikomatsakis
Copy link
Contributor

I like it

@nikomatsakis
Copy link
Contributor

I agree with @jonathandturner that this particular case is slightly worse but I also think those messages are bad and something we are trying to revamp in a major way for NLL. =)

@estebank
Copy link
Contributor Author

@GuillaumeGomez what do you think? Should we merge this as is?

@GuillaumeGomez
Copy link
Member

Like I said, it doesn't make much differences for me. I gave the two opinions I had on the question but both are fine for me. :)

@stokhos stokhos added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 6, 2018
@stokhos
Copy link

stokhos commented Jul 6, 2018

Ping from triage @estebank , we haven't heard from you, will you have time to look into this PR, in near future?

@estebank
Copy link
Contributor Author

estebank commented Jul 6, 2018

will you have time to look into this PR, in near future?

@stokhos I don't see what's left for me to do on the PR.

It allows to focus more easily on the other messages, which depending on what we want might be better or worse.

That is something to be done on a case by case basis.

So do we want to focus on help messages, attract users' attention to tips or do we want to keep the attention on the first/initial/main error?

I believe that we need to make it easier to read the errors. There are people that are driven towards the error message and others driven towards the labels. With this change we are removing the attention seeking highlight from the notes, which should only be used to further understand the error, not the entry point.

@estebank estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 15, 2018
@stokhos
Copy link

stokhos commented Jul 21, 2018

Ping from triage! @GuillaumeGomez this PR needs to be moved forward.

@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented Jul 21, 2018

Then I suppose it's good to go. Thanks @estebank!

@bors: r+

@bors
Copy link
Contributor

bors commented Jul 21, 2018

📌 Commit ed5dcc3 has been approved by GuillaumeGomez

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 21, 2018
@bors
Copy link
Contributor

bors commented Jul 21, 2018

⌛ Testing commit ed5dcc3 with merge d439d6cde2ca0afe1d6f56e2e494cd1b35f3d7a5...

@bors
Copy link
Contributor

bors commented Jul 21, 2018

💔 Test failed - status-appveyor

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 21, 2018
@kennytm
Copy link
Member

kennytm commented Jul 21, 2018

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 21, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Jul 21, 2018
…, r=GuillaumeGomez

Remove highlighting from secondary messages

Deemphasize the secondary messages so that all other highlights stand
out more.

<img width="684" alt="" src="https://user-images.githubusercontent.com/1606434/41261199-7b4fe96e-6d8f-11e8-8619-04d170617df2.png">
@bors
Copy link
Contributor

bors commented Jul 21, 2018

⌛ Testing commit ed5dcc3 with merge 0ad6179...

bors added a commit that referenced this pull request Jul 21, 2018
…meGomez

Remove highlighting from secondary messages

Deemphasize the secondary messages so that all other highlights stand
out more.

<img width="684" alt="" src="https://user-images.githubusercontent.com/1606434/41261199-7b4fe96e-6d8f-11e8-8619-04d170617df2.png">
@bors
Copy link
Contributor

bors commented Jul 22, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: GuillaumeGomez
Pushing 0ad6179 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.